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(54) Method and receiver for managing service information in a digital television system 



(57) The invention relates to a process for managing 
service information in a digital television system. 

The process comprises, with regard to a receiver of 
the system, the following steps: 

programming of means (5) for the selective extrac- 
tion of information from a digital data stream; 
storage of at least some of the extracted informa- 



tion; 

marking of a stored item of information as being up- 
dated or non-updated depending on the program- 
ming, relating to this item of information, of the said 
means of selective extraction. 

The invention also relates to a device for imple- 
menting this process. 
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Description 

[0001] The invention relates to a process for managing service information in a digital television system especially 
information relating to programme guides. 

[0002] The invention applies among other things to digital television decoders. 

[0003] . Electronic programme guides (or EPGs) are software applications used within digital television systems 
These applications provide the viewer with an interface whereby he may consult information relatinq typically to the 
programmes broadcast. . 

[0004] The information is transmitted by multiplexing appropriate data packets in the digital data stream A name 
which is often used for this type of data is "Service Information" (or simply "SI"). 

[0005] The service information is broadcast periodically, the period being chosen in particular on the basis of the 
available passband and of the frequency of user requests for information. This is because, when the user wishes to 
view rapidly the information relating to a large number of programmes, it is desirable for the waiting time-between the 
users request for the information and the response to this request to be as short as possible. One means consists in 
furnishing each receiver or decoder with a large amount of memory in order to store as much information as possible 
so as to be able to respond immediately to the user's requests. It turns out that the total amount of information broadcast 
is such that this solution is not viable in a mass product intended for the general public, at least at the current price of 
sem.conductor memories. Moreover, the fact that the item of information alters constantly would compel the receiver 
or decoder to devote a considerable part of its resources to the updating of the information, whether it be used sub- 
sequently or not. In particular the number of data packet demultiplexing filters which can be programmed and imple- 
mented simultaneously is limited. 

[0006] The two French Patent Applications FR 96 f 0067 and FR 96 10068 filed on 9 August 1 996 in the name of 
the applicant relate to a module for managing service information in a receiver, especially a digital television decoder. 
Appl,cat.on FR 96 10067 relates to a television receiver and a process for managing the updating of certain types of 
data stored in an internal dynamic database in the receiver, whereas application 96 10068 relates to a process for 
mdex.ng, in the internal database, data received and extracted from the digital stream. Application WO 98/09430 
des.gnat.ng Europe, the United States, Japan and China, claims priority of application FR 9610066. Applications claim- 
ing pnonty of FR 960067 have been filed in Europe (Publication number 0823798), China (Pub 1175826A) the United 
States (application 08/906597), Indonesia (application P-972774) and Japan (Pub 98508/98) 
30 [0007] These two patents also describe the requests which an application such as a programme guide may issue in 
order to request this or that item of information from the module for managing the SI data, which module programs the 
demultiplexer: permanent or one-off request, expected or unexpected. 

[0008] According to these two patents, data corresponding to permanent requests are stored in the internal database 
until the deprogramming of the permanent request, whereas data extracted following a one-off request are not kept in 
35 memory beyond the immediate processing. 

[0009] In the case where the user retraces his steps through the programme guide, it is possible that recently erased 
data may have to be extracted once again. 

[0010] The invention proposes to increase the reactivity of the system in such a case. 

[001 1] The subject of the invention is a process for managing service information in a digital television system char- 
acterized in that it comprises, with regard to a receiver of the system, the following steps: 

- programming of means (5) for the selective extraction of information from a digital data stream 

- storage of at least some of the extracted information; 

- marking of a stored item of information as being updated or non-updated depending on the programming relatinq 
4t > to this item of information, of the said means of selective extraction. 

[0012] When the means of selective extraction of an item of information from the stream are deprogrammed the 
information stored beforehand in the internal database of the receiver are held in the base, but marked as non-updated 
[0013] Thus, on the one hand, if the user retraces his steps, it is possible to supply him with this non-updated infor- 
mation very rap.dly without having to wait for a new extraction. Although the memory of the receiver is thereby kept 
busier, it is possible easily to delete the data which are not updated should the memory become saturated 
[0014] According to a particular embodiment of the invention, following the formulating of a request of extraction of 
an item of information by an application, the programming and storage steps are carried out as follows: 

- if the requested item of information is present in the database, transfer of the item of information to an application 
programming of the means of selective extraction of the item of information from the data stream and updating of 
the item of information in the database, following the extraction of the Hem of information from the data stream 

- if the requested item of information is absent from the database, programming of the means of selective extraction 
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and storage of the item of information in the database of the decoder following its extraction from the data stream. 

[0015] Thus, the item of information, when it is present in the base, is transmitted with no waiting to the application 
which made the request therefor. This is the case in particular if it was stored following a recent request by an application, 
$ for example in the case in which a user retraces his steps through a programme guide. There is a high chance that 
the item of information thus stored is still current, or at least that it will satisfy the user. 

[001 6] The resources for searching for an item of information in the data stream and for storing this item of information 
are used only to search for or to update an item of information requested by an application, and not indiscriminately 
for the storage and updating of information. 

to [0017] According to a particular embodiment, the search means comprise a demultiplexer. 

[001 8] According to a particular embodiment, the marking of a stored item of information as being updated is effective 
throughout the period following the extraction of said item and during which the search means are programmed to 
extract a new value therefrom. Once an item has been extracted, and as long as the filter for extracting it remains 
active, the item can be considered as updated. It can also be considered as updated if an unchanged version number 

15 is detected in the stream. 

[0019] According to a particular embodiment, the marking of a stored item of information as being non-updated 
following its extraction from the stream is carried out in conjunction with a deprogramming of the means for searching 
for this item of information. 

[0020] According to a particular embodiment, the marking of an item of information as non-updated comprises the 
20 associating of this item of information with the date on which the means of selective extraction corresponding to the 
item of information were deprogrammed. 

[0021] This characteristic makes it possible to determine the time elapsed since the last update of the item of infor- 
mation. This makes it possible to judge its obsolescence, especially if its periodicity of transmission is known. 
[0022] According to a particular embodiment, should the database of the receiver become saturated, information 
25 marked as non-updated are erased in order of seniority of date. 

[0023] According to a variant embodiment, the marking of an item of information is communicated, with this item of 
information, to an application having requested the item of information. 

[0024] Thus, the application can decide on the use made of this item of information depending on the state of the 
marking. 

30 [0025] According to a variant embodiment, should the database of the receiver become saturated, information 
marked as non-updated are erased in order of seniority of date. 

[0026] According to a variant embodiment, a non-updated item of information displayed on a screen by an application 
is identified visually as being non-updated. 

[0027] The user is thus alerted to the state of the item of information and to the risk that the latter may perhaps be 
35 obsolete. 

[0028] The subject of the invention is also a receiver in a digital television system in which service information, and 
especially programme guide information, is transmitted, the said receiver comprising: 

a data stream demultiplexer, the said demultiplexer comprising programmable filters for selective extraction of 
40 information from the said stream, 

the said receiver being characterized in that it comprises: 

a memory intended to contain a database of the said receiver, the said database comprising information ex- 
tracted previously; 

45 - means for marking the information of the database as updated or non-updated. 

[0029] According to a variant embodiment, the marking as updated or as non-updated is performed as a function of 
the programming of the said multiplexer. 

[0030] According to a variant embodiment, the device furthermore comprises a clock used for marking non-updated 
50 information. 

[0031] Other characteristics and advantages of the invention will emerge through the description of a nonlimiting 
embodiment. This embodiment is illustrated by the appended figures in which: 

Figure 1 is a block diagram of a television receiver in accordance with the present embodiment, 
55 - Figures 2a to 2c are timecharts of the exchanges taking place between an application, the data management 
module and the demultiplexer of the device of Figure 1 , 

Figure 3a, respectively 3b is a state diagram illustrating the manner of operation of a one-off request, respectively 
a permanent request, 
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- Figure 4 is a diagram of a screen of an application, namely an electronic programme guide 

- Figure 5 ,s a d.agram of the database maintained by the management module at a given instant 

ES? T° r ,ur,her n i " formation regarding the format and contents of MPEG and DVB service data segments and 
tables, reference will be made in particular to the following three documents: segments and 

23, lS 6 300 " Sp6CifiCati0n for Service ln <°rmation (SI) in Digital V.deo Broadcast (DVB) systems - January 

So S ca^.Mp 8 EG I S^s^nd ^ " M ° Vin9 ^ Audio " ^commendation H.220, 

SnT^ ," Di9ital Broadcastin 9 s V stems for television: Implementation guidelines for the use of MPEG-2 sys- 
tems, Gu.del.nes on .mplementation and usage of service information. V 

KcasSgT 1 ^ 3 blOCK diaQram ° f ^ ime9rated decoder/receiver f or digital television, of DVB type (Digital Video 

SL^f ,SZ 8 inVen,i ° n ,S n0t Hmi,ed t0 thiS Physical env| ronment but may easily be adapted to some 

" ,ranSm,SS, ° n ° f Sen " ce da,a ' for exam P' e transmission by way of modulated La within the frame flyback ~ 

[0035] The decoder of Figure 1 is linked to an antenna 1 , itself linked to a tuner 2 of the decoder The signal delivered 

Z^».T2££l 3 dem0dU,at ° r 3 dem0dU ' ated ^ ~ — ^ -on^oSS 

!?°! 6] ol^ lattSr iS f ° r exam P' e a demultiplexer similar to the one described in French Patent Application 95 1 57R7 
ed on 29 December 1 995 in the name of THOMSON MULTIMEDIA. The demultiplexer 5 compos ^ a number o' 
hltenng reg.sters^termed fitters by extension, programmed by a microprocessor 23 as a f unctio Z The various apph 

rZT*TT« ? y th V eCOder domu *P'«" —pares the contents of the filtering register with certain pa- 
ameters of the data packets and loads the data packets corresponding to a positive comparison P 

Eted C ' arrty ° f dia9ram ' ° nly the m ° St imp ° rtant -sections of the microprocessor 23 are 

[0038] The audio or video packets or segments filtered by the demultiplexer are stored in predefined areas of a buffer 
memory 6 awaiting applications. If necessary, the information is firstly decrypted by a decker drcuit 7 as a functln 
of the user's entrtlement, before being stored in this buffer memory 6 creun / as a function 

EZL H ACC0 I d,n9 o' 0 the Pr8Sent 6Xample ' there are five ^Plications: an audio decoder 16 a video decoder 17 a 
SSEiSS?, ft an aCC6SS COn,r °' aSSemb,V (COmPnSin9 ,hG d6Crypter 7 - a checki "9 rnicrocomrot^ l and an 
35 "ce l^Z^TrllT" " h ™" — « » Coprocessor card 10), as^l 

f^? deC ° der B l S ° COmprises an inf rared interfa ce for a remote control 24. the said interface also beina linked 

e^n? ,Cr H PrOC r S !° r H 23 la,ter iS C ° nneCted t0 a memor V 12 contai ™9 operating sysZ as WSLTH 
res.dent or downloaded programs for implementing the applications 

40 Sn^o! ^ 1 3 ' inked 10 the SWitCh6d tele P hone ^twork 1 4 is also controlled by the microprocessor 

E2 h f ^ 96nerat0r 15 a " OWS ,he 9enerati0n of command me ™ s ° r graphics relathg to 7h parameters of 
onet^ZZ P ? rt ' CU,ar a . PpliCation - The vide ° si 9" a ' 9^erated by this character gene Jo felled with 
t J u h? Tf ° r,g,natm 9 frorn tne video dec °der 1 7 or from the Teletext decoder 1 8 heading for alrst IcA^ 

45 !°^ 3] AcCOrd,n 9 to ,he P resem exam P'e embodiment, the service data management module is physically sceakino 
fn P n?m m T* bV J he miCr °P rocessor ' a " h °"9h conceptually it is an application ^ J^ZSaTS 
nthe manner of an aud.o or video decoder, for which dedicated circuits are used P ' 

[0044] The module is an interface between the service data (MPEG and DVB tables and segments) and customer 

so TIT" (Pr H 09ramme 9UideS ' ^Purchasing, interactive games, etc.). I, manages the requests rom cu tome 
SSST T ""I ma ' an intemal databaSe ° n the Stren 9 th of ,he se rvice data received 

SedChe'^cro^;:: 1 6XamPle emb ° diment ' ^ CUSt ° mer aPPl — iS * P-9— guide which is also 

tr a ra P z,r^m~ 

request '-tion identification mechanism For this purpose, an ident^^^ 

-ssuedandtransmittedtogetherwiththis request. This identifier is, ied to the notification of res^nse by the ^ 
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module. 

[0048] Figures 2a to 2c illustrate the three cases of exchanges, following a request, between the customer application, 
the service data management module and the source of these data, namely the demultiplexer/buffer memory/micro- 
processor assembly. 

s [0049] Figure 2a relates to the case in which the internal database ("cache memory") contains the information item 
requested by the customer application. The latter's request is followed by notification of availability of this item of 
information. The item of information being in this case present in the database, the notification of response is almost 
immediate. In this case, no item of data has been transferred to or from the demultiplexer. Data transfer to the application 
is carried out through a buffer memory to which the management module writes the data. The area of the buffer memory 

io to be used is identified in the application's request. The application, once notified, will read the data therefrom in due 
course. This case will be seen in greater detail later. 

[0050] Figure 2b illustrates the case in which the item of information requested does not appear in the internal da- 
tabase. In this case, the customer application's request is likewise followed by notification by the management module 
to the application intended to inform it of the temporary unavailability of the information item, and then of a command 

15 addressed by the management module to the demultiplexer When the segment or segments corresponding to the 
information item sought have been found in the data stream, demultiplexed and stored in the buffer memory, the de- 
multiplexer notifies the SI management module that these segments are available. After reading and reformatting the 
data of the segments, the management module in turn notifies the customer application that the information item sought 
is available. As in the previous case, the module writes the item of information sought (which may be just some of the 

20 data from the segment) to a buffer memory allocated during its initial request by the customer application. Hence, in 
this case this notification arrives more slowly than in case 2a. 

[0051] Figure 2c illustrates the case in which the initial request such as that of Figure 2a specifies that the changes 
in the information sought are to be signalled. In this case, the filters of the demultiplexer which have enabled the data 
packet containing this item of information to be extracted from the data stream are maintained at the previous values 
2S instead of being deactivated. This type of request, termed a permanent request, will be described in greater detail below. 
[0052] According to the present example embodiment, there are four types of request: 

(a) One-off request: 

30 [0053] When such a request is addressed by the application to the management module, the latter makes its re- 
sources (filter and memory) available only up to the moment at which the data requested are transferred to the appli- 
cation. The resources are in principle freed immediately. 

(b) Expected one-off request: 

35 

[0054] This request possesses the characteristics of the one-off request, but possesses a lower priority. The man- 
agement module maintains two FIFO type memories, one for the expected requests and the other for the unexpected 
requests. Expected requests which are waiting are always processed after the unexpected requests. 

40 (c) Permanent request: 

[0055] The resources of the management module are maintained, even after the data requested are demultiplexed 
and transferred. Whenever a change occurs in these data, notification is transmitted to the application. The manage- 
ment module therefore performs systematic monitoring, doing so until the application sends a command to interrupt 
45 this monitoring. 

(d) Expected permanent request: 

[0056] This request is similar to the permanent request, but has a lower priority level. 
so [0057] The priorities attached to the requests do not of course in any way prejudge the order in which the data relating 
to these requests are actually received. This order depends also on factors such as the periodicity of each data item 
and the instant at which the request is formulated relative to this period. 

[0058] Figure 3a is a state diagram of a one-off request, whereas Figure 3b is a state diagram of a permanent request. 
[0059] Whenever an application formulates a request, a request type. must be associated therewith. 
55 [0060] In the case of a permanent request, the data retrieved from the stream are additionally stored in the internal 
database in the management module. This is not the case for the data extracted following a one-off request, for which 
no copy of the data is preserved. When a new version of a table containing data relating to a permanent request is 
detected, the appropriate data from this table are compared with the data in the database. A change of version is 
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indicated by a change of value of a parameter termed 'Versionjd" or "version_number» transmitted with each table 
A notification of update is not Iransmitted a priori unless at least one of these data has been modified The version 
identifier of the table "versionjd" is in fact modified regardless of the modification occurring in the table even if it 
relates only to data not requested by an application. This mechanism avoids the transfer of redundant data between 
the application and the management module. 

[0061] Moreover, application requests are distinguished from elementary requests. Application requests are as their 
name indicates, requests issued by the customer applications. An application request is translated by the SI manage- 
ment module into as many elementary requests as necessary. In the present context, an elementary request is one 
which can be translated into a s.ngle filter at demultiplexer level. The elementary requests are determined in such a 
way that the data to which they relate do not overlap. 

[0062] Two tables of requests are maintained by the SI module: A table of application requests and a table of ele- 
mentary requests. 
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Table of application requests 


Request identifier 


Type 


Function 


Wait 


SingNB 


SList 


Parameters 
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Table of elementary requests 


Request identifier 


Function 


State 


Type 


Date 


Number of application requests 


Parameters 













































[0063] The table of application requests comprises the following elements for each request: 

a request identifier, 

- the type of the request (expected one-off, unexpected one-off . ..). 
the function of the request, 

- 'Wait': Number of corresponding elementary requests waiting, that is to say which have not yet given rise to a 
■c SP °Mo e if notification to the ^Plication having issued the request is sent when this digit is equal to zero) 

- SingNB : Number of elementary requests which have not given rise to a transfer of data to the buffer memory ' 
SList . List of identifiers of elementary requests associated with this application request 

- parameters linked with the application request (for example, identification of a service for which a list of events is 
sougnty. 

[0064] The table of elementary requests comprises the following elements for each elementary request: 

an identifier for the request, 
the type of the request, 
the function of the request, 
the state of the request, 

- the number of application requests linked with the elementary request, 
the date of inactivation of the request (if relevant) 

parameters linked with the elementary request. 

[0065] .When the SI management module translates an application request into an elementary request or requests 
it checks whether or not the table of elementary requests already contains these requests. A new elementary request 
is inserted into the corresponding table only if an identical request does not already exist. This makes it possible to 
avoid the use of the resources of the demultiplexer to redundant ends. 

[0066] Two elementary requests are regarded as identical if they have the same function and the same parameters 
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If an elementary request is already present in the corresponding table, then the SI module checks the type of the 
already-existing elementary request. 11 this type has lower priority than the type of the new elementary request (this 
being the application request type which gave rise to this new elementary request), then the type of the existing ele- 
mentary request is modified so as to take the new value. The classification of request types from lowest to highest 
5 priority is: expected one-off, expected permanent, unexpected one-off, unexpected permanent. 

[0067] The subsequent elements of the table of application requests are updated following the programming or mod- 
ifying of corresponding elementary requests: Wait, SList. The link with the contents of the table of elementary requests 
is thus established. 

[0068] The table of elementary requests also has another role: it provides the possibility of determining whether or 
10 not a data item is present in the base and if this data item is or is not up to date. 

[0069] The "State" field of a request from this table can take one of the following values: 

'Waiting': the request is active, but the data have not yet been received; 
'Ready': the request is active and the data have been stored in the database and are updated; 
is - 'Non-updated': the request is no longer active and the data are stored in the database, but are no longer updated. 

[0070] The table of elementary requests also counts up, for each elementary request, the number of relevant active 
application requests. This number is incremented or decremented as dictated by the breaking down of new application 
requests or the deprogramming of old requests. When this number falls to zero for an elementary request, the state 
20 of the latter becomes 'non-updated' (if previously its state was 'Ready') : in other words, it is inactive. The data extracted 
previously, if there are data, remain stored in the base. 

[0071] An elementary request for which the number of application requests falls to zero and which has not, for one 
reason or another, stored information in the base, is deleted from the table. The corresponding filter of the demultiplexer 
is freed. The reasons for this may be diverse: overly fast deprogramming before data could be obtained, requested 
25 data not broadcast, etc. 

[0072] An inactive elementary request can be reactivated by an appropriate application request, or be deleted from 
the table of elementary requests when it becomes necessary to free some space in the occupied memory in the da- 
tabase and when the data corresponding thereto are erased. 

[0073] The date of inactivation of a request is stored in the table of elementary requests. In the present case, this 
30 date consists of the value of the system clock, this clock being synchronized with that of the encoder. However, it is 
also conceivable to employ some other type of clock. 

[0074] When the data corresponding to an elementary request (of one-off or permanent type) are demultiplexed, 
they are transferred to the buffer memory. This transfer takes place as many times as there are links with application 
requests. The number of elementary requests 'SingNB' in each of the relevant application requests is decremented. 

35 Notification of the availability of the data by the SI management module to an application is performed only when this 
number reaches zero for this application, that is to say when all the elementary requests linked with the application 
request issued by the application have given a result and have transferred it into the buffer memory. 
[0075] By contrast, should there be a subsequent change of data in the base in respect of an elementary request, 
this change is notified immediately to the relevant applications. 

40 [0076] Figure 5, described later, gives an example of the two tables in a specific case. 

[0077] When an elementary request is stamped as being 'non-updated', this does not mean to say that the data in 
the base are no longer actually up to date, but simply that there is a probability that this is so, given that the request 
from which they arise has not been maintained for a period of time which can be determined from the above mentioned 
date of inactivation. 

45 [0078] When the management module transfers data into the buffer memory with a view to transfer to the application, 
the contents of the 'Date' field or fields and of the 'State' field or fields is also stored there. These values will be read 
by the application which will decide on the use of this information. When the state is 'Ready', the data are up to date. 
When the state is 'non-updated', they are not up to date and the 'Date' field indicates how old they are. If the application 
is a programme guide, the data displayed stamped as not being updated are displayed in such a way as to identify 

50 them as such: for example, shaded display or display in a colour which is distinct from an item of information which 
would be updated. 

[0079] When the state of an elementary request is 'Ready', the data are up to date. To indicate this to the application, 
during the transfer of the data, the transferred value of the 'Date' field is zero. 

[0080] Although according to the present embodiment, only the permanent elementary requests (whether expected 
55 or not) give rise to storage of the data extracted in the database, there is provision according to a variant embodiment 
also to store the data corresponding to one-off requests. It will of course be necessary in this case also to maintain the 
elementary requests of one-off type in the corresponding table. 

[0081] Whether or not non-updated data have been read in the internal database following a request, the filters of 
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[0083] When an elementary request is generated and no corresponding filter already exists it is the first tvoe of tutor 
wh,ch s employed. Once the corresponding item of information has been detected an extrac ed Mf he elem Jn ™ 
rirT' tyP6 ' Va ' Ue ° f the VerSi ° n number extracted is incremented and addedlo he hotter 

^"jRzssr ment,oned above is thus crea,ed ,i is ,hus cenain that the — — -srs i e r. 

IW! th S °! C ° UrSe C ° nCeivable to s,ore tne val ^s of the version numbers in the database 

Sanntl nTr tS ^ ^ (b) t0n tables giVin 9 info ^tion about the configuration of the network or networks 

nl P ! 9SS . S6,V,CeS and 6VentS transmi «^. The tables are identified by particuiar PID ?PaSS£j£' 

SfLTl? 8 ? ma " a9ement m0dule instructs ^ eternal indexation of the networks, channels and services avail 
malm i ir !T mm d6X f ° r th,S Semce ,n the ^tabase maintained by the module. 

[0090] In a DVB system, a service can be located in a unique manner via the path comprising the following variables: 

networkjd (network identifier), 
(transport_stream_id; originaLnetworkJd) pair, 
servicejd (actual service identifier). 

[0091] The three variables are natural integers coded over 16 bits 

seSs ITelTZlT Created ' " St *° r netW ° rkS ' ° ne ,iSt « Channels to ' «* -twork and one list of 

So, t8ble C ° mPnSeS ' iSt ° f Channe ' S <0r thiS " et ™ k as we » « lis, of services available for each 

[0096] For each channel, a lis, o, sen/ices is created, comprising the identifiers o, the services described by the NIT 
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table. Each service in a list is indexed over 7 bits. The logic key of a service in the database therefore comprises in 
total 16 bits: 4 network index bits, 5 channel index bits and 7 service index bits 

[0097] An event of a service will be identified with the aid of the 16 bits designating this event (event_id variable of 

the table), to which will be added the 16 bits of the logic key of the associated service. 

[0098] The structure of the database (excluding events) is organized according to the following structures: 



Database 



NetworksListAddress 



IS 







Networks list 
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NetworkAddress 


20 
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NetworkAddress 
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NetworkAddress 
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NetworkAddress 
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NetworkAddress 
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NetworkAddress 
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NetworkAddress 


30 
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NetworkAddress 






NextNetworksAr ravAdaress 
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40 



Network 



Network I dent i f ier ( M network_id" ) 
Networ kName 
Channels List Address 
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NextServicesArrayAddress 
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.-?^£YA5.?i.ll^A£L er ("service id") 
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CurrantN^xtSvant 

Cur rent Event Identifier _ ( "Event_ici M ) 

CurrentEventStart ..(."start^ime" ) 

Cu r r en t Even t Dura t i on rduration" ) 

CurrentEventState ( " running^status M ) 

Cur rep t Even tTitleLength { "event_naine_J.engt:h" ) 

Cur rent Even tTi tie 

Cur re n tEve n it De s cr i p t i o n Le ng t h ("tex t__l e n g t h " ) 
Cur re nt Even t Desc r i p t i o n 
NextEvent Identifier ( "Event_id M ) 
.NextEventSta 

NextEvent Duration ( "duration" ) 
NextEventState ( "runn ingest a tus " i 

Next Event Tit le 

Next Even t De script i on L e n . g t h ( " t e x t 1 eng t h " ) 
NextEvent Description 



30 

[0099] The variables whose name contains the term "Address" are pointers to memory areas corresponding to the 
start of a data structure. 

[0100] The other variables correspond to information extracted from the data stream. To aid understanding, these 
variables are followed in brackets and quotation marks by the name used in document (a). 

35 [0101] It will be noted that the lists of networks, channels and services are each organized into arrays, each array 
being composed on the one hand of eight pointers to data structures of network, channel or service type, and on the 
other hand of a pointer to a possible array containing the remainder of the list. This last pointer is null when there is 
no other array, that is to say when an array contains the last elements of a list. This latter pointer is not indexed. 
[0102] The arrays contain eight elements, this corresponding to a power of two. This makes it possible to determine 

40 the array which contains a desired pointer by masking, in this case, the last three bits of the channel index. 
[0103] The database array contains a pointer to the array containing the first part of the list of networks. 
[0104] The NetworksList array contains the pointers to the first eight networks. According to the present example 
embodiment, there are at most two NetworksList arrays containing the complete list of networks. 
[0105] The Network array contains the information relating to a given network, as well as a pointer to a first array of 

45 the list of channels associated with this network. 

[0106] The structure of the other arrays is similar to what has just been stated. Moreover, it is easy to extend it to 
the events and to other types of data. 

[0107] According to a variant embodiment, the requests relating to the data concerning the structure of the network, 
of the channels and of the services are requests of permanent type, the aim of this being to keep the image of the 
so array constantly up to date in the database. 

[0108] In their exchanges with the management module, the applications use logic keys. These are translated by 
the module into a memory address corresponding to the location at which the item of information is stored. They form 
part of the parameters stored in the tables of requests. 

[0109] Figure 5 is a. diagram of the database qf the management module in the case of the existence of a network, 
55 comprising two channels, each channel itself comprising two services. 

[0110] The above mentioned table of application requests gives the list of requests being formulated by the applica- 
tions. According to the present example, the only request in progress is a request of permanent type intended to retrieve 
the list of services present on a network. 
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w 



IS 



InVrlLlu Pr8S f m CaSS ' 9iV6n ,hat 1h6re are tW ° Channe,s in the ne,work ' two elementary requests are necessary 
Iff the application request: one elementary request per list of services or else per channel is written into the 
table of elementary requests. 

[0112] In the figure, the filters corresponding to each elementary request are to be found on the left of the table of 
elementary requests. 

[0113] It is assumed that at the instant illustrated by Figure 5, the service lists have been input a first time Given the 
permanent nature of the application request, the corresponding filters, as well as the contents of the database relating 
o this request are ma.nta.ned after the first occasion on which the expected data are obtained 

of tS elernen'TntheTst^" 9 *' bfanCheS i0in ' n9 " * ^ " elemen, h ^ lhl corres P° nd *> the index (logic key) 

oTr^irv J. he thic P m a f ° n t n ° W Se6kS l ° ° f b,ain NSt ° f 8VentS in pr ° 9reSS in the network Tnere is one event in progress 
pe service, this makes ,t necessary to filter the corresponding "Current/Next EIT' table ("Event Information Table") It 

! tTT fem f ?, d6r ° f the aCC ° Unt th9t SUCh a ,able is indeed broadcast f ° r each service, that is to say 
mi l S tk E,T -P resent - foll °w 1 ng_flag of the service description table have the value 1 for these services 
[01 16] The request issued by the application comprises, for a given service, the following parameters: 

_ .... a request identifier, ._. „ ... . . __,_„_ _, 

the type of the request, 
the logic key of the relevant service, 
so - a memory address of a buffer memory intended to receive demultiplexed data from the SI module. 

[0117] It will be assumed firstly that the base contains no data item relating to the events in progress or the next 
miT« " tk ,S Say th3t ,ab ' e ° f elementar V re ^ests contains no elementary request relating to these date 
2S E ■ 11 , Pr ,° 9 r T 6 9Uide appNca,ion searches for example for the current and next events of the second service 

n J££r; ^ Z° Channe ' ( "°" ) ° f fifSt n6tW ° rk ( "°" ) - Th,S redUeSt f0ll0WS a co ™ d ^ the user to display 
3 ° pr ° 9ramme in P r °9 ress and the Programme immediately after the programme in progress of a 
given service, for example Canal+ (French TV channel). 
[0119] The logic key of the service concerned is then: 
0000 00000 000001 

30 [01 20] A corresponding application request is transmitted to the SI module. This request will be of permanent type 
Given that within the framework of this example, only the current and next events of a single service are asked for by 
the appl.cat.on, this request is elementary and ought not to be broken down further by the SI module The elemental 
request is written into the corresponding table of requests. elementary 

35 [nihil 1 Addi t tionaMy '. tha Sl modu,e Programs a filter of the demultiplexer so that the filtering of the EIT table relating 

q »rr 5 T COrreC " y ThS Va ' Ue °' th6 P ' D ° f the Packets comprisin 9 the -Current/Next" EIT fables is 

0x0012. according to document (a). The values of the service identifier ("service_id"), channel identifier 

Lh?2^?" ,a T- J** "° ri9 ' nal network - id ") whi ^h are necessary in order to determine which is the correct EIT 

n the^h?! n,T ° 3 t aVa " able ln thS dat3baSe by Virtue of the '°9 ic key The state of the elementary requesf 

in the table of elementary requests is moreover set to the "Wait" state 

JO [0122] Once the correct EIT table has been detected, the SI module extracts from the packets the values of the data 
to be «ored -n its infernal database. According to the present example embodiment, these data are those appear^ 
in the "CurrentNextEvent" data structure described above. The SI module notifies the requesting appTitton of the 

fh ^CuZVnlT a ,Tr Pi8 t ,h6m int ° the bUff6r mem0fy reSerVed beforeha n d hy the application Inthe database 
4S , CurrentN extEventAddress" address pointer of the Service data structure corresponding to the path indicated by 

TJl T Pr ° 9rammed Wi,h the memor y address corresponding to the "CurrentNextEventAddress" »e The 
state of the elementary request in the table of elementary requests switches from "Waif to "Ready" 
[0123] It should be noted that there is at most one current event and one next event per service There is therefore 
no reason «o index ,n this particular case, the structure of the "CurrenfNext Even," date structure since n hSE£ 
fully identified by the logic key leading to the service on which it depends V 

50 E!f2 , ""I 6 ^ ™°T bS di " erem " ,hS C ° ntentS ° f the EIT ,ables containing chronologica. series of events were 
loaded. In this case, indexation could prove to be necessary. 

tTrSLfih 0 " 9 timS ^ an ° ,her ' apP ' ication wiN cancel i,s r equest, for example following a command by the user 
to rcclose the programme guide. Given that, in this case, there are no more application requests in progress which 
make re erence to the elementary request relating to the currenf/next event, the SI modulw the liters oUhe 

ZTlTiL Wr,,eS K he PreSen ' ValUS ° f thS SyStSm C ' pCk in, ° ,he " Da,e " field of the table of primitive requests 
J £ h ° the request becomes "non-u P da,ed", assuming that data have actually been demultiplexed and stored in 
he base beforehand, which is .he case here In the contrary case, they would simply have been erased from the table 
[0126] According to a variant embodiment, the management module itself generates certain requests relating to the 
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structure of the networks (especially the list of networks and the associated lists of channels) and maintains them 
permanently 

[0127] It should be noted that the invention is not limited solely to the transmission of data by satellite, radio relay or 
cable, but may be implemented in any system in which data or packets of data appear periodically in the data stream. 
s This is the case in particular for recorded or prerecorded data streams. 

[0128] Moreover, whereas the examples given relate more particularly to service data, it is clear that the invention 
is not limited to this type of data. So-called private data may, tor example, be processed in an analogous manner 

10 Claims 

1. Process for managing service information in a digital television system characterized in that it comprises, with 
regard to a receiver of the system, the following steps: 

75 - programming of means (5) for the selective extraction of information from a digital data stream; 

storage of at least some of the extracted information; 

marking of a stored item of information as being updated or non-updated depending on the programming, 
relating to this item of information, of the said means of selective extraction. 

20 2. Process according to Claim 1 , characterized in that following the formulating of a request of extraction of an item 
of information by an application, the programming and storage steps are carried out as follows: 

if the requested item of information is present in the database, transfer of the item of information to an appli- 
cation, programming of the means of selective extraction of the item of information from the data stream and 
25 updating of the item of information in the database, following the extraction of the item of information from the 

data stream; 

if the requested item of information is absent from the database, programming of the means of selective ex- 
traction and storage of the item of information in the database of the decoder following its extraction from the 
data stream. 

30 

3. Process according to one of Claims 1 or 2, characterized in that the means of selective extraction comprise a 
demultiplexer. 

4. Process according to one of Claims 1 to 3, characterized in that the marking of a stored item of information as 
35 being updated is effective throughout the period following its extraction and during which the means of selective 

extraction are programmed to extract a new value therefrom. 

5. Process according to one of Claims 1 to 4, characterized in that the marking of a stored item of information as 
being non-updated following its extraction from the stream is carried out in conjunction with a deprogramming of 

40 the means for searching for this item of information. 

6. Process according to Claim 5, characterized in that the marking of an item of information as non-updated comprises 
the associating of this item of information with the date on which the means of selective extraction corresponding 
to the item of information were deprogrammed. 

45 

7. Process according to Claim 6, characterized in that if the database of the receiver becomes saturated, information 
marked as non-updated is erased in order of seniority of date. 

8. Process according to one of the preceding claims, characterized in that the marking of an item of information is 
50 communicated, with this item of information, to an application having requested the item of information. 

9. Process according to one of the preceding claims, characterized in that a non-updated item of information displayed 
on a screen by an application is identified visually as being non-updated. 

55 10. Receiver in a digital television system in which service information, and especially programme guide information, 
is transmitted, the said receiver comprising: 

a data stream demultiplexer (5), the said demultiplexer comprising programmable filters for selective extraction 
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of information from the said stream, 

the said receiver being characterized in that it comprises: 

' a da,abas ' 01 ,he MM ^ " 8aid da,abasa «»'•• 

- rrraans (23) tor marking Ihe information o( the darabase as rjpdatsd or norttrpdatad 

ZSZSSSEZSZ' CBims 1 Oor 11 • cna,acMrizM h ,ha ' " ' urtham °' a ■ ** — * -*« 
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